feat(android): [Part 4] Prefer Activity ui.load transactions over Nav3 transactions - #6484

PR Stack (Nav3 Lifecycle)

• fix(android): Nav3 multi-Activity support now plays nicely with nav roots that don't have a SentryNavEffect #6480
• ref(android): [Part 1] Refactor #6481
• feat(android): [Part 2] Start a new nav transaction when returning to a nav root #6482
• fix(android): [Part 3] Stop attributing Nav3 data to screens without a SentryNavEffect #6483
• feat(android): [Part 4] Prefer Activity ui.load transactions over Nav3 transactions #6484

📜 Description

When the user opens an Activity from a Nav3 root, that Activity's ui.load transaction is now bound to the scope instead of being blocked by the Nav3 root's nav transaction (API 29+), matching Nav2. A Nav3 transaction blocked by a closing Activity's ui.load is retried once.

† TTID and TTFD were never affected. Both spans are children of ui.load itself, so they're sent whether or not ui.load is bound to the shared IScope. Binding only decides which transaction ambient spans (HTTP, db, etc.) attach to.

How this PR fixes things

This PR withdraws the lease when a covering Activity is created. On API 29+ this happens in onActivityPreCreated, which runs before ActivityLifecycleIntegration tries to bind ui.load, thereby allowing the ui.load transaction to beat out the nav transaction.

Below API 29 there's no onActivityPreCreated, so creation is reported from onActivityCreated, meaning the nav transaction beats out the ui.load transaction.

Known gaps

Documented in the package README.

• A ui.action transaction from the gesture that caused the return can still block the nav transaction.
• Spans produced between the return and the closed Activity's destruction attach to its ui.load.
• An Activity that's left without being destroyed triggers no retry.

Addressing the last two would require updating ActivityLifecycleIntegration to unbind a finishing Activity's ui.load when it pauses. That'd change behavior for every app and not just users of Nav3, so I haven't included it here. We could follow-up at some point if we care to. Nicely, tackling things in ActivityLifecycleIntegration would have the happy side effect of simplifying the heuristics we have to use here.

💡 Motivation and Context

Nav2 lets an Activity's ui.load transaction take precedence, but Nav3 blocked it whenever the Activity was opened from a Nav3 root, so the Activity's auto-instrumented spans went elsewhere. Withdrawing the lease only on resume (#6483) also left the covering Activity's onCreate/onStart work attributed to the previous root.

addresses: JAVA-785

💚 How did you test it?

• Unit tests
• Integration tests
• Had my clanker thoroughly test the pre- and post-stack behavior via the Nav3 sample app i) to verify the stack really does what it claims to and ii) to ensure it doesn't introduce any regressions. (Did so on both pre-API 29 and post-API 29 devices.)

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.
• Public API changes reviewed by another Mobile SDK team member or implemented according to the develop docs spec.

🔮 Next steps

Last PR in the stack. Once the stack is merged into the collection branch, squash-merge #6480 into main.

⚠️ Merge this PR using a merge commit (not squash). Only the collection branch is squash-merged into main.